Skip to content

interp: split loaded vs applied tool offset params (#5401-#5409, #5081-#5089)#4228

Merged
grandixximo merged 2 commits into
LinuxCNC:masterfrom
grandixximo:fix/4216-applied-tlo-params-master
Jul 4, 2026
Merged

interp: split loaded vs applied tool offset params (#5401-#5409, #5081-#5089)#4228
grandixximo merged 2 commits into
LinuxCNC:masterfrom
grandixximo:fix/4216-applied-tlo-params-master

Conversation

@grandixximo

Copy link
Copy Markdown
Contributor

Forward-port of #4219 (merged to 2.9) to master, fixing #4216.

#5401-#5409 again hold the loaded tool's stored offset (refreshed on M6 / G10 / init), restoring the behavior probing routines in the wild rely on. The offset actually applied to motion by G43/G43.1/G43.2 moves to the new parameters #5081-#5089, and is zeroed by G49.

Two commits:

Full test suite passes locally (291 tests, 0 failed).

…1-#5089)

Commit 725231f made #5401-#5409 report the tool length offset actually
applied to motion. That matched the documentation, but broke probing
routines in the wild that read #5401-#5409 right after an M6 (without a
following G43) to get the loaded tool's stored offset. See LinuxCNC#4216.

Restore the long-standing behavior of #5401-#5409 and put the applied
offset in a new parameter set instead:

  - #5401-#5409: loaded tool's stored offset, refreshed from the tool
    table on tool change (M6), at startup, and by G10 L1/L10/L11.
    Reverts the convert_setup_tool / set_tool_parameters /
    default_tool_parameters / init_tool_parameters changes from 725231f
    so existing routines keep working.
  - #5081-#5089: tool length offset actually applied to motion, written
    by convert_tool_length_offset for G43, G43Hn, G43.1, G43.2, and
    zeroed by G49. This is the value 725231f intended to expose.

Docs (overview.adoc, g-code.adoc) and the interp_parameter_def.hh enum
updated to describe both sets.

Fixes LinuxCNC#4216. Re-addresses LinuxCNC#2994 without the regression.
@grandixximo grandixximo merged commit 9bcf823 into LinuxCNC:master Jul 4, 2026
16 checks passed
@wucke13

wucke13 commented Jul 4, 2026

Copy link
Copy Markdown
Contributor

@grandixximo I think this did miss to update the absolute Z position formula example on the G38.n gcode?

@grandixximo

grandixximo commented Jul 4, 2026

Copy link
Copy Markdown
Contributor Author

I did not look at the absolute Z position formula, because I had a vague memory of having separated the formula out from #5403, but reading your message gave me a bit of a scare that I might have missed something, fortunately I did not miss, it was related before my changes in 6da626e
the new official formula is

G38.2 Z-100 F100
#<zmachine> = [#5063 + #5023 - #5422]

In both 2.9 and 2.10

The new one above is simpler than this following initial proposal we had

#<zmachine> = [#5063 + #[5203 + #5220 * 20] + #5213 * #5210 + #5403]

Which is not working well anymore, has to be changed to either

#<zmachine> = [#5063 + #[5203 + #5220 * 20] + #5213 * #5210 + #5083]

or the new one from the new docs

G38.2 Z-100 F100
#<zmachine> = [#5063 + #5023 - #5422]

So it should all be good, nothing missed, just gave me a heart attack lol

@wucke13

wucke13 commented Jul 4, 2026

Copy link
Copy Markdown
Contributor

Ah, sorry for the scare --- I didn't read careful enough. Two additional notes:

  • At first I thought #5422 was a typo, but indeed the #542x parameter block starts with 0, not 1, so Z is 2, not 3.

  • In the current docs, it reads:

    5420-5428 - Current relative position in the active coordinate system including all offsets and in the current program units for X, Y, Z, A, B, C, U, V & W, volatile.

    This is indeed the only parameter that is described as relative. I wonder what the word conveys there, I would assume that this is an absolute (but work-, as opposed to machine-) coordinate system? If indeed it is relative, then, relative to what?

@grandixximo

Copy link
Copy Markdown
Contributor Author

I think it's in contrast to what is referred to as "absolute machine position" which is what you reference with G53. So it is relative to the active coordinate system if I interpret it correctly

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants